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SECTION  I. 


INTRODUCTION . 

The  purpose  of  this  Technical  Report  is  to  provide  the 
Draft  Computer  Resources  Life  Cycle  Manangement  Plan 
(CRLCMP).  The  results  are  provided  in  the  form  of  the 
attached  CRLCMP  as  requested  by  the  CMOS  Program  Office. 

SUMMARY .  Not  Used . 


CONCLUSION.  Not  Used. 


SECTION  II. 


RESULTS . 

Our  input  is  presented  in  the  attached  draft  report. 
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CMOS  Computer  Resources  Life  Cycle 
Management  Plan  (CRLCMP) 


1.  Introduction. 

a.  Overview.  The  CMOS  Computer  Resources  Life  Cycle  Management  Plan  (CRLCMP) 
serves  as  the  life  cycle  management  document  for  the  development  of  the  Air  Force  Cargo 
Movement  Operations  System  (CMOS).  CMOS  is  an  Air  Force  standard  information 
system  which  provides  automated  data  processing  (ADP)  support  to  the  Air  Force's 
transportation  community.  The  primary  goals  of  the  CRLCMP  are  to: 

(1)  Document  the  computer  resources  development  strategy,  the  philosophy  for 
life  cycle  management,  and  the  methodology  for  development  of  computer 
resources; 

(2)  Document  the  software  support  concept  and  the  resources  needed  to  achieve 
that  support  posture; 

(3)  Identify  the  applicable  directives  (regulations,  operating  instructions,  technical 
orders,  etc.)  for  managing  computer  resources  in  the  CMOS  system;  and 

(4)  Define  any  changes  or  new  directives  needed  for  operation  or  support  of 
computer  resources  in  CMOS. 

b.  Scope  and  Applicability.  The  CRLCMP  is  created  and  updated  under  the  direction  of 
the  United  States  Air  Force  in  response  to  HQ  USAF  Program  Management  Directive 
(PMD)  5272(4)/  PE  #3861  OF.  dated  5  December  1986,  as  revised  5  June  1992.  The  PMD 
directs  the  development  of  an  automated  system  to  support  regular  and  crisis  cargo  and 
personnel  processing,  documentation,  movement  and  tracking  for  the  base-level 
Transportation  Management  Office  (TMO). 

CMOS  has  requirements  for  a  two-way  data  interface  with  the  Standard  Base  Supply 
System  (SBSS),  the  Consolidated  Aerial  Port  System  (CAPS  II),  the  Stock  Control  and 
Distribution  System  (SC&D),  the  Air  Force  Consolidation  Containerization  Point  System 
(CCP),  the  Base-Level  Transportation  Workload  Reporting  and  Productivity  System  (B- 
TWRAPS),  the  Headquarters  On-line  System  for  Transportation  (HOST),  the  Computer 
Aided  Load  Manifesting  (CALM)  system,  the  Department  of  the  Army  Movement 
Management  System  -  Redesign  (DAMMS-R),  the  Terminal  Management  System/Water 
Clearance  Authority  system  (TERMS/WCA),  and  the  Air  Clearance  Authority  (ACA)  system. 

CMOS  also  has  requirements  to  send  data  to  the  Air  Force  Command  and  Control  System 
(AFC2S),  the  Central  Data  Collection  Point  (CDCP)  system,  and  the  Enhanced 
Transportation  Automated  Data  System  (ETADS),  and  to  receive  data  from  the  Combat 
Ammunition  System  -  Base  level  (CAS-B),  and  the  Contingency  Operations  Mobility 
Planning  and  Execution  System  -  Base  level  (COMPES-B). 


c.  References. 

(1)  Requirements  Documents. 

CMOS  Operational  Requirements  Document  (ORD)  (Draft  Final),  28  September 
1992. 

Information  Systems  Requirements  Document  (ISRD)  -  CMOS.  18  April  1986. 
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(2)  Directives. 


CMOS  Program  Management  Directive  (PMD)  5272(1)/  PE  #3861  OF.  5  December 
1986,  as  revised  19  December  1991 . 

(3)  Regulations. 

DODR  4500.32  Military  Standard  Transportation  and  Movement  Procedures 
(MILSTAMP). 

AFR  14-1,  “Configuration  Management",  December  1988. 

AFR  4-29,  "Air  Force  Data  Management  and  Standards  Program",  April  1990. 

AFR  28-4,  “USAF  Mobility  Planning",  27  March  1987. 

AFR  71-4,  "Preparing  Hazardous  Materials  for  Military  Air  Shipment". 

AFR  71-9,  "Air  Force  Packaging". 

AFR  75-1,  "Transportation  of  Material". 

AFR  75-2,  "Defense  Transportation  Management  Regulation". 

AFR  80-14,  "Test  and  Evaluation",  November  1986. 

AFR  205-16,  "Automated  Data  Processing  Security  Policy,  Procedures,  and 
Regulations". 

AFR  310-1,  "Management  of  Contractor  Data",  March  1983. 

AFR  700-10,  "Information  Systems  Security",  March  1985. 

AFR  800-14,  "Life  Cycle  Management  of  Computer  Resources  in  Systems", 
September  1986. 

(4)  Standards. 

DOD  5200.28-STD,  Trusted  Computer  System  Evaluation  Criteria",  December  1985 
DOD-STD-21 67A,  "Defense  System  Software  Development",  February  1988. 
DOD-STD-2168,  "Defense  System  Quality  Program". 

MIL-STD-480B,  "Configuration  Control  Engineering  Changes.  Deviations  and 
Waivers",  July  1988. 

MIL-STD-483A.  "Configuration  Management  Practices  for  Systems.  Equipment, 
Munitions,  and  Computer  Programs",  June  1985. 

MIL-STD-490A,  "Specification  Practices",  June  1985. 

MIL-STD-1521B,  Notice  1,  Technical  Reviews  and  Audits  for  Systems,  Equipment, 
and  Computer  Programs",  December  1985. 


(5)  Plans. 

CMOS  Communications-Computer  Systems  Program  Plan  (CSPP),  1  September 
1987. 

CMOS  Test  and  Evaluation  Master  Plan  (TEMP)  for  Increment  1, 19  December  1991. 
CMOS  Integrated  Logistics  Support  Plan  (ILSP),  undated. 

(6)  Other  Documents. 

CMOS  System  Concept,  24  August  1987. 

CMOS  Increment  I  Contract  Number  GS-OOK-89-AJD01 1 1 . 

Updated  Final  (Change  03),  System/Segment  Specification  (SSS),  Increment  II.  13 
December  1991. 

Revised  Final  (Change  02)  System/Segment  Design  Document  (SSDD),  13 
December  1990. 

Revised  Final  (Change  01)  Requirements  Traceability  Matrix  (RTM),  23  December 
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1991. 

Updated  Final  Software  Requirements  Specification  (SRS)  for  the  Applications 
Computer  Software  Configuration  Item  (CSCI),  22  February  1991. 

Updated  Final  SRS  for  the  Communications  CSCI,  18  January  1991. 

Final  SRS  for  the  System  Environment  CSCI,  14  December  1990. 

Updated  Final  Interface  Requirements  Specification  (IRS),  22  March  1991. 
Interface  Design  Document  (IDD),  Version  2.3.0, 4  September  1992. 

Software  Design  Document  (SDD)  for  the  Applications  CSCI,  Version  2.3.0,  4 
September  1992. 

SDO  for  the  Communications  CSCI,  Version  2.3.0, 4  September  1992. 

CMOS  Monthly  Program  Status  Report,  (latest  version). 
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2.  System  Concepts. 

a.  Operational  Concept.  CMOS  will  support  the  peacetime  and  wartime  activities  of  an 
Air  Force  base  TMO  associated  with  the  movement  of  cargo  by  any  mode,  and  passengers 
on  military  aircraft.  CMOS  will  provide  the  capability  to  effectively  plan,  document,  and 
manage  outbound  and  inbound  movements.  The  system  will  accumulate  and  aggregate 
movement  requirements  data  provided  by  electronic  interface  or  manual  entry;  track  the 
completion  of  transportation  actions;  prepare,  print,  and  transmit  movement  documentation 
to  notify  en  route  and  destination  sites  of  the  movement;  and  track  receipt  and  distribution 
activities.  The  CMOS  operational  environment  is  described  in  the  following  paragraphs: 

(1)  CMOS  will  operate  at  Air  Force  active  duty,  Air  Force  Reserve,  and  Air  National 
Guard  sites  around  the  world  (approximately  203  sites  in  total).  CMOS  will  be  used 
primarily  by  TMO  personnel.  The  CMOS  configuration  depicted  in  Figure  2-1 
provides  a  representation  of  the  physical  environment  at  most  active  duty  sites,  as 
established  by  Increment  I  of  CMOS,  and  the  expansion  provided  in  Increment  II  to 
support  mobility  processing.  The  expansion  includes  adding  the  Logistics 
Applications  of  Automated  Marking  and  Reading  Symbols  (LOGMARS)  capability  and 
additional  Personal  Computer  (PC)  workstations.  A  total  of  1 5  PC  workstations  may 
either  be  directly  connected  to  the  CMOS  Local  Area  Network  (LAN)  or  connected 
through  a  Multipoint  Attachment  Unit  (MAU),  to  be  used  at  the  discretion  of  the  TMO 
to  meet  workload  demands.  PC  workstations  will  be  moved  as  required  from  their 
peacetime  locations  to  support  mobility  operations. 

(2)  The  CMOS  operational  environment  will  be  supported  by  hardware  and  software 
from  the  Standard  Muiti-user  Small  Computer  Requirements  Contract  (SMSCRC), 
Desktop  III,  Unified  Local  Area  Network  Architecture  (UL4NA),  and  LOGMARS 
contracts.  Components  from  these  contracts  will  be  integrated  with  non- 
developmental  software  (NDS),  or  contractor-developed  software. 

(3)  At  all  active  duty,  Air  National  Guard,  and  Air  Force  Reserve  sites,  one  AT&T 
3B2/600GR  minicomputer  from  the  SMSCRC  contract  will  be  used  as  the  TMO  host. 
All  host  processor  units  will  be  connected  to  Uninterruptible  Power  Supply  (UPS) 
devices. 

(4)  The  Desktop  III  microcomputer  will  be  used  as  the  hardware  platform  for  the  user 
interface  in  each  of  the  functional  areas.  The  MS-DOS  operating  system  will  be  used 
to  support  an  ORACLE  data  base  interface  to  the  central  processor.  The  Packing  and 
Crating,  Air  Freight,  Surface  Freight,  Air  Cargo  Terminal,  and  Transportation  Control 
Unit  stations  will  have  both  laser  and  dot  matrix  printers  attached.  The  remaining 
stations  will  have  only  a  dot  matrix  printer. 

(5)  Components  from  the  UL4NA  contract  will  be  used  to  provide  the 
communications  path  between  the  host  processors  and  the  PC  workstations,  primarily 
via  an  802.3  compliant  Ethernet  L0N.  The  L4N  will  also  be  used  to  access  the 
Defense  Data  Network  (DDN)  to  provide  long-haul  communications  for  CMOS.  Both 
processors  will  have  DDN  interface  capability,  although  only  one  line  will  be  provided 
to  the  nearest  DDN  Concentrator.  The  line  will  be  switched  to  the  backup  processor 
in  the  event  of  failure  in  the  TMO  host  at  sites  with  two  host  processors. 

(6)  CMOS  will  also  use  Automatic  Digital  Network  (AUTODIN)  in  the  event  of  DDN 
failure,  and  to  interface  with  those  systems  whic.i  are  not  yet  DDN-capable.  Diskette 
transfer  will  be  accomplished  using  the  Automated  Data  Reports  Submission  System 
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Figure  2-1.  CMOS  Environment 


(ADRSS)  and  Base  Level  AUTOOIN  Message  Extraction  System  (BLAMES) 
software. 

(7)  Transfer  of  data  between  CMOS  and  SBSS  will  be  accomplished  using  the 
Interactive  Communications  Interface  (Id)  protocols. 

(8)  CALM  software  will  be  present  on  those  stations  that  need  to  do  aircraft  load 
planning.  Data  will  be  exchanged  between  CMOS  and  CALM  via  the  CMOS  central 
data  base. 

(9)  LOGMARS  bar  code  scanning  devices  will  be  used  for  rapid  and  accurate 
collection  of  transportation  and  shipment  data.  The  LOGMARS  Hand  Held  Terminal 
(HHT)  will  be  used  to  update,  retrieve,  or  display  data  contained  within  the  CMOS 
data  base.  Communications  between  the  HHT  and  the  CMOS  data  base  will  be 
either  through  an  RF  base  station  connected  through  a  PC  workstation  to  the  CMOS 
LAN  or  via  cabling  directly  to  any  PC  workstation  on  the  LAN. 

(10)  The  primary  uses  of  NDS  will  be  to  support  the  central  data  base  and  to  provide 
Electronic  Data  Interchange  (EDI)-formatted  communications.  Specifically,  the 
ORACLE  data  base,  and  its  associated  suite  of  Structured  Query  Language  (SQL) 
and  support  facilities  will  form  the  core  of  the  CMOS  software.  EDI  software  will  allow 
CMOS  users  to  extract,  package,  and  manage  messages  to  and  from  EDI  trading 
partners  using  Transaction  Set  858. 

(11)  Electronic  mail  will  be  used  to  notify  the  user  of  MICAP/999  or  priority  1  and  2 
messages  received  by  the  system.  Each  CMOS  user  will  have  the  capability  to 
access  any  of  the  available  functional  areas. 

(12)  There  are  numerous  existing  and  proposed  interfaces  to  external  systems. 
Changes  to  these  systems  will  require  revisions  to  the  CMOS  system  functions  which 
manage  inbound  and  outbound  data  transfers. 

b.  Support  Concepts.  The  CMOS  hardware  will  be  purchased  from  the  standard 
contracts  listed  in  the  preceding  paragraph.  The  hardware  will  be  serviced  through  a 
maintenance  option  from  a  standard  contract  or  from  local  maintenance  arrangements. 
Establishment  of  repair  versus  replacement  criteria  is,  and  will  remain,  the  responsibility  of 
the  CMOS  SPO.  The  Integrated  Logistics  Support  Plan  (ILSP)  makes  specific 
recommendations  on  repair  versus  replacement  procedures.  Logistics  support  is  the 
responsibility  of  the  CMOS  SPO  and  should  be  included  in  the  equipment  maintenance 
contract.  All  expendable  supplies  will  be  purchased  from  standard  Air  Force  contracts.  The 
software  support  concept  is  of  Type  "E"  (from  AFR  800-14,  attachment  8),  since  Air  Force 
Materiel  Command  (AFMC)  (formerly  Air  Force  Logistics  Command  (AFLC))  is  not 
responsible  for  any  phase  of  the  software  support  function. 
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3.  System  Description. 

a.  Overview.  The  CMOS  Increment  I  software  automates  the  standard  functions  of  the 
base-level  TMC,  i.e.,  packing  and  crating,  shipment  planning,  and  the  air  freight  and 
surface  freight  work  centers.  The  CMOS  system  will  allow  the  transportation  activity  to 
automate  all  of  its  functions  in  order  to  effectively  support  the  variety  of  missions  with  which 
it  is  tasked.  Increment  II  functions  will  automate  transportation's  support  of  installation-level 
mobility  activities,  including  deployment,  reception,  and  redeployment  of  combat  forces. 
Interfaces  with  additional  automated  systems  beyond  those  found  in  Increment  I  software 
are  also  implemented. 

The  CMOS  architecture  is  composed  of  four  Hardware  Configuration  Items  (HWCIs)  and 
three  Computer  Software  Configuration  Items  (CSC  Is).  The  functions  performed  by  the 
Local  Area  Network,  Host  Processor,  PC  Workstation  and  LOGMARS  HWCIs  are  described 
in  paragraph  b.  below.  Paragraph  c.  describes  the  functions  of  the  CMOS  Applications, 
Communications,  and  System  Environment  CSCIs. 

b.  Computer  Hardware.  Detailed  listings  of  HWCI  components  may  be  found  in  Tables 
6-3  through  6-10. 

(1)  The  LAN  HWCI  will  provide  the  communication  path  between  the  Host  Processors 
HWCI  components  and  the  PC  Workstation  HWCI  components.  The  LAN  will  facilitate  the 
transfer  of  CMOS  functional  data,  user  mail,  and  other  system  data  throughout  the  local 
CMOS  system.  The  LAN  will  allow  the  various  CMOS  users  to  process  cargo  in  a  timely 
manner  and  to  inform  other  CMOS  users  of  cargo  movements,  both  on  site  and  outside  the 
local  CMOS  community. 

The  LAN  will  be  implemented  using  ULANA  components.  The  LAN  requires  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE)  802.3  compatible  LAN  cards,  coaxial  cable,  and 
a  cable-attached  transceiver. 

(2)  The  Host  Processor  HWCI  includes  the  TMO  minicomputer,  as  well  as  support 
hardware  such  as  printers  and  UPS  equipment.  The  host  processor  will  provide  the 
external  communications  functions,  maintenance  and  control  of  the  central  integrated  data 
base,  control  of  the  LAN.  and  restart  and  recovery  functions. 

The  SMSCRC  will  provide  one  AT&T  3B2/600GR  minicomputer,  currently  configured  with 
32  Megabytes  (Mb)  of  RAM,  a  300  Mb  system  disk  and  two  300  Mb  data  base  disks.  A  120 
Mb  streaming  tape  drive  will  be  used  for  system  backup  and  will  support  the  requirement  for 
data  base  integrity.  An  eight-millimeter  cartridge-tape  backup  unit  is  also  available.  For 
large  volume  reports,  the  host  processors  will  share  an  800  line  per  minute  printer.  UPS 
units  will  provide  10  minutes  of  operability  to  allow  a  controlled  shutdown  of  the  data  base. 

System  external  interfaces  will  either  be  through  an  X.25  connection  to  the  local  DDN 
concentrator,  or  via  diskette  into  AUTODIN. 

(3)  The  PC  Workstation  HWCI  includes  the  PC  itself  and  directly  connected  printers.  The 
PC  workstations  will  provide  the  functionality  needed  by  the  Shipment  Planning,  Packing 
and  Crating,  Surface  Freight,  Air  Freight,  Outside  the  Continental  United  States  (OCONUS) 
ACA,  Air  Cargo  Terminal,  Air  Passenger  Terminal,  Mobility  Control  Unit,  Transportation 
Plans  and  Programs,  Load  Planning,  Transportation  Control  Unit  and  CAS-B  work  centers 
to  process,  document,  and  report  cargo  movement.  PC  workstations  will  be  relocated  from 
their  normal  peacetime  locations  and  placed  in  the  work  centers  required  to  support  mobility 
operations. 
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The  Desktop  III  microcomputer  will  be  used  as  the  standard  PC  Workstation,  configured 
with  4  Mb  of  Random  Access  Memory  (RAM),  and  84  Mb  hard  drive,  one  3.5"  1.44Mb 
floppy  drive,  one  5.25"  360  kilobyte  floppy  drive,  and  a  Video  Graphics  Array  (VGA)  color 
monitor.  An  Ethernet  card  will  be  installed  to  allow  connectivity  to  the  CMOS  LAN.  Some 
functional  areas  will  have  both  a  laser  printer  and  a  dot  matrix  printer,  while  others  will  have 
only  the  dot  matrix  printer. 

(4)  The  LOGMARS  HWCI  includes  the  LOGMARS  HHT  and  scanner.  The  LOGMARS 
equipment  will  be  used  for  rapid  and  accurate  transaction  input  into  the  data  base,  and  will 
be  the  main  input  device  for  tracking  cargo  movements  throughout  the  TMO  facility.  The 
HHT  will  interface  with  the  PC  Workstation  through  a  communications  dock  connected 
through  an  RS-232  port. 

The  INTERMEC  Trakker  9440  Portable  Transaction  Manager,  the  INTERMEC  Model  1500 
Laser  Scanner,  and  the  INTERMEC  Trakker  40D  Communications  Dock  will  be  the 
LOGMARS  equipment  used. 

c.  Computer  Software.  A  reference  for  detailed  descriptions  of  each  of  the  CSCIs  may 
be  found  in  Appendix  F. 

(1)  The  CMOS  Applications  CSCI  provides  access  to,  and  execution  of,  all  user 
applications.  Functions  supported  include  System  Administration,  Process  Outbound 
Cargo,  Process  Inbound  Cargo,  User  Services,  Perform  Air  Passenger  Function, 
Transportation  Plans  and  Programs,  and  Command  and  Control  Operations. 

(2)  The  Communications  CSCI  provides  all  direct  communication  support  for  both  internal 
and  external  communications.  Functions  provided  include  the  DDN  Adapter,  AUTODIN 
Adapter,  LAN  Adapter,  Mail  Adapter,  ICt  Adapter,  Incoming  Message  Manager,  and 
Outgoing  Message  Manager. 

(3)  The  System  Environment  CSCI  provides  Non-Developmental  Software  (NDS)  support 
to  the  other  CSCIs.  System  Environment  software  on  the  Host  Processor  HWCI  equipment 
includes  the  Host  Processor  OS,  TCP/IP  WIN/3B  software,  Office  Automation  System,  High 
Order  Language  Interface,  Relational  Data  Base  Management  System  (RDBMS)  for  the 
Host,  ICI  Interface,  and  EDI  software.  System  Environment  software  found  on  the  PC 
Workstation  HWCI  equipment  includes  the  PC  Workstation  OS,  Net  BIOS  Interface,  Video 
Drivers  software.  High  Order  Language  Interface,  RDBMS  for  the  PC,  LAN  PC  Interface, 
Windows  software,  CALM  software,  Graphics  Software  System  (GSS)  Drivers,  Foreign 
Language  Laser  Fonts,  and  OCR  Laser  Fonts.  System  environment  software  resident  on 
the  LOGMARS  HWCI  equipment  includes  the  LOGMARS  software. 
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4.  Computer  Resource  Design. 

a.  System  Architecture  and  Integration.  There  are  four  HWCIs  and  three  CSCts  in  the 
CMOS  architecture,  as  described  in  paragraph  3  of  this  document.  Refer  to  Figure  4-1  for  a 
high-level  view  of  how  these  components  are  integrated. 

CMOS  is  not  an  embedded  system,  and  does  not  have  the  built-in-test  and  fault-tolerance 
functions  associated  with  these  types  of  systems,  nor  does  it  have  maintenance  interfaces 
or  special  test  equipment,  except  those  used  by  contract  maintenance  technicians  servicing 
CMOS  hardware. 

Since  CMOS  uses  non  militarized  general  purpose  commercially  available  hardware,  the 
requirements  of  MIL-STD-1750,  "Instruction  Set  Architecture",  and  MIL-STD-1553, 
"Standard  Bus  Architecture",  do  not  apply,  as  per  AFR  800-14,  paragraph  3-10  a.  A  waiver 
to  the  requirement  for  use  of  Ada  as  the  High  Order  Language  has  been  approved  on  the 
grounds  that  the  C  programming  language  is  more  fully  supported  as  an  interface  to  the 
ORACLE  RDBMS. 

The  CMOS  software  has  been  divided  into  three  CSCIs:  CMOS  Applications, 
Communications,  and  Systems  Environment.  "Mission"  software,  as  defined  in  Attachment 
7  of  AFR  800-14,  has  been  grouped  into  the  CMOS  Applications  CSCI.  Both  the 
Communications  and  Systems  Environment  CSCIs  are  composed  of  "support"  software, 
also  as  defined  in  Attachment  7  of  AFR  800-14. 

All  CMOS  hardware,  and  all  System  Environment  CSCI  software,  is  Commercial  Off  The 
Shelf  (COTS)  equipment  purchased  from  standard  government  contracts. 

b.  Product  Improvements.  The  CMOS  architecture  is  modular  in  nature,  to  allow  the 
addition,  replacement,  upgrade,  or  deletion  of  system  functions  and  features  without 
negatively  impacting  other  system  functions  or  features.  Increment  III  of  CMOS  will  be 
used  as  the  vehicle  for  Pre-Planned  Product  Improvement  (P3I)  features.  Addition  of  new 
external  interfaces  will  be  the  most  likely  cause  of  future  expansion  to  the  system. 

Current  memory  reserves  for  the  Host  Processors  are  estimated  at  7.7  Mb  out  of  32 
available.  Memory  reserves  for  the  PC  Workstations  are  estimated  at  2208  Kb  out  of  4096 
Kb  available.  The  LOGMARS  equipment  will  potentially  use  all  896  Kb  of  available 
memory,  with  appoximateiy  755  Kb  of  that  total  used  for  data  structures. 

Hard  disk  reserves  for  the  Host  Processor  are  estimated  at  40  Mb  out  of  300  Mb  total  for 
the  system  disk  (disk  #1),  125  Mb  out  of  300  Mb  for  the  first  data  base  disk  (disk  #2),  and 
140  Mb  out  of  300  Mb  for  the  second  data  base  disk  (disk  #3).  PC  Workstations  will  have 
appoximateiy  27  Mb  free  out  of  84  available. 

c.  Software  Development  Tools  and  Environment.  Software  development  tools  will  be 
used  in  an  Engineering  Support  Laboratory  (ESL),  and  a  Development  and  Test  Laboratory 
(DTL).  The  ESL  is  mainly  used  for  analysis  and  design  efforts.  The  ESL  consists  primarily 
of  commercially  available  equipment  and  software  furnished  by  the  development 
contractor.  The  DTL  consists  of  Government  Furnished  Equipment  (GFE),  Government 
Furnished  Software  (GFS),  and  contractor  developed  software. 

Most  of  the  software  environment  for  the  ESL  is  hosted  on  Sun  workstations  running  the 
Sun  OS.  The  Teamwork  CASE  tool  from  CADRE  Technologies,  FrameMaker 
documentation  tool,  the  ORACLE  RDBMS  and  support  products,  and  a  C  language 
compiler  are  all  hosted  on  the  Sun  system.  RTrace,  Lotus  1-2-3,  a  C  language  compiler 


9 


Figure  4-1.  CMOS  Architecture. 
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and  an  adaptation  of  the  Unix  Source  Code  Control  System  (SCCS)  are  hosted  on  a  PC 
workstation.  MacOraw  II  and  MacProject  are  hosted  on  an  Apple  Macintosh. 

Teamwork  has  several  modules  and  applications.  Teamwork  SA  is  designed  to  aid  analysts 
in  building,  storing,  reviewing,  maintaining  structured  reviews,  and  maintaining  DOD-STD- 
2167A  specifications.  It  handles  data  flow  diagrams,  process  specifications,  and  data 
definitions.  It  provides  consistency  checking  query  functions  and  total  integration  to  other 
objects  in  the  data  base.  Teamwork  RT  uses  decision  tables,  data  control  flow,  and  state 
transition  diagrams  to  perform  real-time  modeling  of  specifications.  It  provides  consistency 
checking,  query  functions,  and  total  integration  to  other  objects  in  the  data  base  (entities, 
attributes,  etc.).  Teamwork  IM  captures  entities,  relationships,  and  attributes  in  the  data 
dictionary  for  development  of  Entity-Relationship  Diagrams.  A  consistency  checker 
provides  a  schema  generator  to  the  ORACLE  Data  Design  Language  (DDL),  relation 
normalizer,  and  total  integration  and  interface  to  other  data  base  objects  (data  flows,  data 
stores,  etc.).  Teamwork  SD  supports  structured  design  methodology  and  standard  notation. 
It  graphically  represents  the  object  of  design  (modules,  invocations,  couples,  and 
connectors).  Design  rule  checking  is  provided  for  completeness  and  validity  based  on  the 
software  design  standards. 

The  ORACLE  RDBMS  capabilities  include  multi-user  support,  a  data  dictionary,  query 
optimization,  distributed  queries,  and  extensive  numeric,  text  and  logical  functions.  Several 
support  products  will  be  used  in  conjunction  with  the  ORACLE  RDBMS.  SQL'Plus  is  the 
SQL  4th  generation  language  interface  to  the  ORACLE  RDBMS  for  querying,  report  writing, 
and  data  transferring.  SQL*Net  allows  networking  the  ORACLE  environment.  SQL'Forms 
is  a  4th  generation  tool  enabling  the  user  to  build  forms-based  applications  and  prototypes 
using  a  screen  painter.  SQL'Report  formats  the  results  of  queries  into  a  report.  The  report 
can  be  formatted  by  specifying  page  size,  numbering,  headers,  footers,  titles,  and  field 
lengths.  The  data  is  selected  from  the  data  base  using  SQL*Plus  statements.  Pro*C  is  a 
pre  compiler  that  converts  a  "C"  source  program  that  includes  SQL  statements  into  an 
executable  program  that  can  be  used  to  access  and  manipulate  data  in  an  ORACLE  data 
base.  SQL'Menu  allows  design  of  custom  menu-driven  interfaces  to  ORACLE  applications. 
Data  base  Add-in  for  Lotus  1-2-3  provides  an  interface  between  Lotus  1-2-3  and  ORACLE. 
SQL'Graph  allows  graphic  representations  of  numerical  data  that  resides  in  the  ORACLE 
data  base  to  be  produced. 

FrameMaker  is  the  document  publishing  system  used  to  create  finished  deliverables. 

Output  from  Teamwork,  MacPaint,  and  MacDraw  can  be  loaded  into  FrameMaker  to 
produce  high-quality  deliverables. 

The  native  C  compiler  provided  with  Unix  operating  systems  will  be  used  to  generate 
programs  for  communications  interfaces  and  complex  algorithms.  A  Microsoft  C  compiler 
will  be  used  to  generate  C  code  on  the  PC  workstations. 

RTrace  provides  the  initial  step  necessary  for  tracking  and  managing  all  requirements.  All 
requirements  to  the  Computer  Software  Unit  (CSU)  level  are  electronically  parsed  by 
RTrace,  reducing  potential  errors  and  saving  time.  These  requirements  can  then  be 
organized,  edited,  allocated,  traced,  and  reported. 

The  Lotus  1-2-3  spreadsheet  program  is  interfaced  with  the  ORACLE  RDBMS  through  the 
Add-In  Manager  function  to  facilitate  affinity  analysis. 

MacDraw  and  MacPaint  are  used  to  produce  diagrams  and  pictures  needed  to  enhance 
documentation. 
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MacProject  provides  the  project  planning  and  charting  tools  to  plan  tasks,  milestones,  and 
events. 

d.  Reusability.  The  Government  and  development  contractor  will  use  the  automated 
capability  of  the  CMOS  software  development  environment  to  capture  the  requirements 
analysis,  database,  and  software  design  information  produced  during  the  design  of  the 
CMOS  system.  This  will  facilitate  the  reuse  of  the  software  modules,  data  and  information 
gathered  during  subsequent  automation  of  transportation  systems. 

e.  Interoperability.  Within  CMOS,  access  to  any  function  shall  be  available  from  any 
workstation.  Access  to  these  functions  shall  be  controlled  through  the  use  of  password 
protection,  not  location.  In  addition,  any  PC  Workstation  hardware  shall  be  interchangeable 
with  any  other  PC  Workstation,  provided  that  necessary  resident  data  has  been  uploaded 
before  the  interchange  takes  place.  Interoperability  with  systems  external  to  CMOS  will  be 
facilitated  by  use  of  hardware  and  software  purchased  from  government  standard  contracts 
wherever  possible.  In  addition,  use  of  the  DDN  and  AUTODIN  networks  to  communicate 
with  external  systems  relieves  CMOS  of  the  responsibility  of  negotiating  unique  data 
transfer  orotocols. 

f.  Additional  Design  Constraints.  In  general,  the  mandated  use  of  GFE  and  COTS 
software  from  the  SMSCRC,  ULANA,  LOGMARS,  and  Desktop  III  contracts  imposes 
constraints  on  the  overall  design  of  CMOS.  In  addition,  there  is  a  conflict  between  the 
CMOS  software  and  the  CALM  load  planning  software  on  the  PC  Workstation  HWCI . 

When  the  CALM  software  is  executed,  the  PC  is  automatically  rebooted  by  CALM.  This 
action  causes  conditions  to  occur  within  the  PC's  memory  that  will  not  allow  the  ORACLE 
software  to  restart  without  resetting  the  PC'  s  memory  (i.e.,  a  warm  boot  of  the  system).  As 
a  result,  users  requiring  a  CALM-generated  load  list  must  select  data  for  input  to  load 
planning,  download  the  data  to  the  PC,  and  receive  a  load  list  from  the  load  planning 
software,  and  upload  the  load  list  to  the  Host  Processor. 
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S.  Organizational  Roles,  Responsibilities,  and  Relationships.  PMD  5272(4)/PE  #3861  OF, 
designates  Air  Force  Communications  Command  (AFCC)  as  the  implementing  command  for  the 
CMOS  Program.  Responsibilities  for  the  program  were  further  delegated  to  the  CMOS  System 
Program  Office  (SPO),  SSC/LGTT.  The  CMOS  SPO  is  responsible  for  contractors  used  to 
develop  the  CMOS  system.  The  SPO  will  contract  for  the  analysis  and  development  of  the 
CMOS  standard  systems.  The  SPO  will  also  contract  for  Independent  Verification  and  Validation 
(IV&V)  efforts  and  technical  support  services  (to  include  technical  evaluations,  requirements 
analysis,  cost  management,  and  other  support  of  the  mission  as  required).  Organizational  roles, 
responsibilities,  and  relationships  of  the  Implementing  Command,  Supporting  Commands, 
Operating  Commands,  Participating  Commands,  and  Other  Agencies/Offices  are  detailed  in  the 
PMD. 
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6.  Resources: 


a.  Personnel.  Air  Force  personnel  requirements  are  detailed  in  Figure  8-1. 

b.  Facilities.  The  CMOS  SPO  will  maintain  a  laboratory  with  the  most  current  hardware 
and  software  configuration.  This  facility  will  be  connected  to  the  ESL  and  the  Development 
and  Test  Laboratory  (DTL)  maintained  by  the  development  contractor  via  a  T-1 
communications  link.  See  Figure  6-2  for  a  representation  of  the  facilities  to  be  used  in 
developing,  testing,  and  supporting  CMOS  computer  resources. 

c.  Training.  No  special  training  is  to  be  provided  by  the  government  in  support  of 
developing,  testing  and  supporting  the  computer  resources. 

d.  Hardware.  CMOS  hardware  will  be  provided  from  standard  computer  acquisition 
contracts  such  as  the  SMSCRC,  the  Desktop  III  Small  Computer  Contract,  the  ULANA 
Contract,  and  the  LOGMARS  Contract.  A  description  of  the  items  needed  to  support 
CMOS  is  provided  in  Figures  8-3  through  6-6.  In  addition,  the  development  contractor  will 
use  Sun  workstations  and  Macintosh  personal  computers  to  support  the  development  of 
CMOS,  as  described  in  paragraph  4.c. 

e.  Software.  CMOS  will  use  the  following  software  development  tools: 

1 .  DOS  Version  5.0  -  used  for  all  CMOS  DOS  batch  processing  to  accomplish  a  variety 
of  tasks.  These  processes  will  execute  in  background  mode. 

2.  Unix  System  V  Shell  Scripts  -  used  on  the  Host  processors  to  accomplish  a  variety  of 
tasks.  These  processes  will  execute  in  background  mode. 

3.  ORACLE  SQL*Plus  Scripts  -  used  to  perform  a  variety  of  tasks  related  to  the 
ORACLE  RDBMS. 

4.  ORACLE  SQL'Forms  -  used  to  construct  user  screens  for  CMOS. 

5.  ORACLE  SQL'ReportWriter  -  used  to  implement  CMOS  requirements  that  call  for  the 
generation  of  reports  based  on  CMOS  data. 

8.  Microsoft  C  Version  5.1  -  used  to  supplement  the  ORACLE  suite  of  products  on  the 
PC  workstation  when  CMOS  requirements  cannot  be  met  by  use  of  those  products 
alone. 

7.  C  language  compiler  prov.led  with  AT&T  UNIX  System  V  -  used  to  supplement  the 
ORACLE  suite  of  products  on  the  Host  Processor  when  CMOS  requirements  cannot 
be  met  by  use  of  those  products  alone. 

8.  IRL  Programming  Language  -  used  for  coding  the  CMOS  LOGMARS  processes. 

9.  PRESCRIBE  Programming  Language  -  The  PRESCRIBE  programming  language  will 
be  used  to  provide  CMOS  users  with  system-generated  forms  on  the  CMOS  Kyocera 
laser  printers. 
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Figure  6-1.  CMOS  Unit  Manpower  Document  (UMD)  Summary. 
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ULANA  LAN 


Figure  6-2.  Software  Development  Environment. 
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Figure  6-3.  Host  Processor  Components. 
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Figure  6-4.  PC  Workstation  Components. 
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6 

Figure  6*6.  ULANA  Components. 
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LOGMARS 

Dual 

Single 

ITEM 

DESCRIPTION 

Processor 

Processor 

Site 

Site 

1004 AA 

BAR-CODE  SCANNER 

3 

2 

1001AC 

PDCD  TRAKKER  9400 

3 

3 

1001 MA 

NICAD  BATTERY  CHARGER 

3 

2 

1001NA 

NICAD  BATTERY  PACK 

6 

4 

1012AA 

PORTABLE  BAR-CODE  ANALYZER 

1 

1001CD 

PORT  CONCENTRATOR 

3 

2 

1010MC 

ASYNC-ASYNC  CABLE  Z-248 

3 

2 

1001QB 

EPROM,  64KB 

6 

4 

Figure  6-6.  LOGMARS  Components. 
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f.  Integrated  Logistics  Support  (ILS).  An  ILSP  has  been  developed  for  the  CMOS  program. 
The  ILSP  is  an  Air  Force  management  plan  developed  and  used  to  manage  the  ILS  process. 

This  includes  the  horizontal  integration  of  the  ILS  elements  as  well  as  their  vertical  integration  into 
the  various  aspects  of  the  program  planning,  engineering,  designing,  testing,  and  evaluation  both 
during  production  and  operation.  It  also  includes  the  integration  of  support  elements  with  the 
mission  elements  of  a  system  throughout  its  life  cycle.  All  participating  activities  are  required  to 
comply  with  the  ILSP  after  it  is  coordinated  with  the  using,  supporting,  training,  and  participating 
commands  and  approved  and  published  by  the  program  management  activity  within  the 
implementing  command. 


7.  Documentation. 


a.  Types  of  Documents.  Program  documentation  includes  ail  documents  produced  under 
contract  for  the  CMOS  program.  Specifically,  this  includes  CMOS  hardware  and  system 
software  documents  produced  under  the  development  contract.  These  documents  are 
categorized  as  development,  testing,  and  supporting  documentation.  Specific  listings  and 
copies  of  these  documents  are  archived  in  the  reference  library  at  the  system  program 
office  facility. 

(1)  Development  Documentation.  Development  documents  are  considered  to  be  the 
documents  used  to  collect  the  user's  basic  functional  requirements,  to  analyze  the 
requirements,  to  integrate  the  requirements  into  a  set  of  CMOS  requirements,  and  to 
develop  and  propose  potential  ADP  system  solutions.  The  documents  listed  below 
are  the  CMOS  documents  required  to  capture  and  analyze  CMOS  requirements: 

(a)  Operational  Requirements  Document  (ORD). 

(b)  Systems/Segment  Design  Document  (SSDD). 


(2)  Testing  Documentation.  Testing  documents  are  considered  to  be  the  documents 
used  to  collect  and  develop  test  plans  and  procedures  to  test  design  unit 
specifications  and  to  verify  operational  effectiveness.  The  documents  listed  below 
are  the  CMOS  documents  required  to  develop  and  test  design  unit  specifications  for  a 
specified  target  area: 

(a)  Software  Test  Description  (STD). 

(b)  Software  Test  Plan  (STP). 

(c)  Software  Test  Report  (STR). 

(3)  Software/Supporting  Documentation.  Supporting  documents  are  considered  the 
documents  used  for  software  development  and  for  development  of  life  cycle  support 
for  the  deployed  design  unit.  The  documents  listed  below  are  the  CMOS  and  DOD 
2167A  documents  required  to  develop  effective  and  efficient  software  and  supporting 
life  cycle  documentation  for  a  specified  target  area: 

(a)  Interface  Requirements  Specifications  (IRS). 

(b)  Software  Requirements  Specifications  (SRS). 

(c)  Software  Design  Document  (SDD). 

(d)  Users  Manual  (UM) 

(e)  Version  Description  Document  (VDD). 

(f)  Operator's  Manual  (OM). 


b.  Data  Rights.  The  government  will  have  unlimited  and  unrestricted  rights  (as  defined  in 
DOD  FAR  Supplement  52.227-7013,  "Rights  in  Technical  Data  and  Computer  Software")  to 
all  data,  documentation,  and  software  developed  and  provided  under  the  CMOS 
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development  contract.  The  government  will  have  Standard  Commercial  Business  Practice 
data  rights  for  COTS  software  and  hardware  items.  The  implementing  command 
(SSC/LGTT)  will  maintain  appropriate  licensing  and  subscription  services  thoughout  the  life 
of  the  system. 

c.  Data  Management  Documentation  is  prepared  using  automated  text  processing 
and  graphics  capabilities  supporting  the  Software  Development  Library  (SDL).  When 
documentation  is  ready  for  formal  review  and  approval,  master  media  are  physically 
controlled  by  the  configuration  management  activity.  Only  those  changes  authorized  by 
designated  responsible  persons  will  be  permitted.  Documents  will  be  provided  to  the 
government  for  analysis  by  electronic  transmission  or  recorded  media  as  specified  in  the 
contract.  Documentation  is  released  as  engineering  documentation  with  all  the  safeguards 
required  for  corporate  and  contractual  records. 

A  document  release  record  is  prepared  for  each  controlled  document  maintained  in  the  SDL 
for  CMOS.  The  record  identifies  each  document  by  identifier  and  title.  It  contains  the  initial 
released  document  revision  level  and  date  of  issue.  The  record  is  updated  to  reflect  the 
approval  of  each  change  or  release  of  subsequent  revision  levels.  This  record  contains  the 
following: 

a.  System  name  (CMOS) 

b.  Project  ID  (e.g.,  Incr  or  Mgmt) 

c.  Contract  Data  Requirements  List  (CDRL)  (e.g.,  A031) 

d.  Contract  Line  Item  Number  (CLIN) 

e.  Document  title  (e.g.,  Updated  Configuration  Management  Plan) 

f.  Version  Name 

g.  Scheduled  Date 

h.  Author 

i.  Reason  Delivered 

j.  Current  Status 

k.  Publication  Date 

l.  Delivery  Date 

m.  Acceptance  Date 

n.  Acceptance  Status 

o.  Document  Control  Number  (e.g.,  3599CMP*027*.05) 
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p.  Library  Storage  Location 


8.  Acquisition  Management  Practices. 

a.  Software  Development  Strategy.  The  CMOS  program  will  use  a  combination  of  DOD- 
STD-2167A  and  Information  Engineering  (IE)  techniques.  The  IE  techniques  produce  a 
data-driven  system  which  limits  redundancy  through  data  standardization  and 
normalization.  The  data-driven  method  provides  a  stable  data  structure  which  promotes  the 
ease  of  building  incrementally.  This  methodology  supports  a  system  engineering  approach 
for  capturing  requirements  which  are  effectively  allocated  to  hardware  and  software.  This 
approach  produces  a  system  design  which  balances  trade-offs  between  computer  hardware, 
software,  and  communications.  The  life  cycle  of  the  CMOS  program  is  shown  in  Figure  8-1 . 

b.  Boards  and  Committees. 

(1)  Configuration  Control  Board  (CCB).  The  CCB  is  composed  of  representatives 
from  CMOS  program  functional  areas,  SSC  support  agencies,  and  participating 
commands.  The  CMOS  Program  Manager  or  his  designated  representative  will  chair 
and  direct  each  CCB  meeting.  The  procedures  for  this  board  are  defined  in  the 
Configuration  Management  Plan  (CMP). 

(a)  Responsibilities. 

1)  Configuration  control  of  CMOS  software  and  hardware  developed  or 
acquired  during  CMOS  development. 

2)  Manage  established  baselines. 

3)  Act  on  proposed  changes  to  baselines. 

4)  Review  and  validate  all  program  impacts  by  approving  or 
disapproving  proposed  changes  to  an  approved  baseline. 

5)  Establish  and  implement  priorities. 

6)  Provide  configuration  management  guidance  and  direction  to 
operating  commands. 

(b)  Interfaces. 

1)  Evaluate  proposed  changes  pertaining  to  cost,  schedule,  or 
baseline  submitted  by  the  government  and/or  contractor. 

2)  Provide  Major  Command  (MAJCOM)  Software  Configuration  Control 
Sub-Boards  guidance. 


(2)  Computer  Resources  Working  Group  (CRWG).  The  CRWG  is  composed  of 
representatives  from  CMOS  program  functional  areas,  SSC  support  agencies, 
participating  commands,  supporting  commands,  and  operating  commands.  The 
chairman  of  the  CRWG  is  the  CMOS  Program  Manager  (SSC/LGTT),  who  will 
coordinate  and  direct  each  CRWG  meeting.  Specific  responsibilities  for  the  CRWG 
are  described  in  the  CRWG  charter  contained  in  Appendix  D  of  this  document. 

(3)  Interface  Control  Working  Group  (ICWG).  The  ICWG  serves  as  the  official 
communications  link  between  program  participants  to  resolve,  document,  and 
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Figure  8*1.  CMOS  Life  Cycle. 
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coordinate  external  interface  matters  with  other  major  programs  such  as  SBSS  and 
CAS-8.  Procedures  for  the  ICWG  are  contained  in  the  Configuration  Management 
Plan  (CMP). 

(4)  Computer  Security  Working  Group  (CSWG).  The  CSWG  is  chartered  as  an 
advisory  forum  with  organizational  and  computer  systems  security  expertise.  The 
purpose  of  the  CSWG  is  to  provide  the  CMOS  program  with  a  review  of  security 
policy,  design,  and  implementation  strategies. 

c.  Configuration  Management. 

(1)  Governing  Directives.  See  Section  1  for  applicable  directives. 

(2)  Special  Procedures. 

(a)  Contractor  Tasks.  Task  orders  are  used  to  request  the  contractor  to 
perform  development  activities.  The  contractor  is  responsible  for  configuration 
management  of  the  software  development  process.  The  Software 
Development  Plan  (SDP)  will  be  the  document  used  to  evaluate  and  monitor 
the  contractor's  configuration  management  procedures.  The  contractor  will 
notify  the  government  of  ail  Class  I  and  Class  II  engineering  changes  to 
baselines.  Class  I  changes  that  affect  Government  controlled  established 
baselines  will  require  the  contractor  submitting  an  Advanced  Change/Study 
Notice  (ACSN).  The  ACSN  will  be  reviewed  by  the  Government  and  if 
approved,  will  authorize  the  contractor  to  prepare  an  Engineering  Change 
Proposal  (ECP).  Detailed  procedures  for  processing  ACSNs  and  ECPs  are 
found  in  the  contract  and  the  CMOS  CMP. 

(b)  Development.  The  contractor  is  responsible  for  the  development 
configuration  during  the  development  phase.  The  software  development 
process  will  follow  the  procedures  detailed  in  DOD-STD-2167A  as  tailored  to 
meet  the  requirements  of  this  contract.  The  software  development  steps  are 
followed  by  specific  reviews  which  must  be  completed  before  proceeding  to  the 
next  step.  The  details  of  each  review  are  found  in  MIL-STD-1521B. 

d.  Documentation  Review  or  Approval. 

(1)  Governing  Directives.  See  Section  1  for  applicable  directives. 

(2)  Special  Procedures.  The  program  office  is  responsible  for  receiving  and 
distributing  documents  produced  under  the  CMOS  development  contract.  A 
reference  library  is  maintained  at  the  system  program  office  facility.  In  addition,  the 
Data  Management  office  in  the  SSP  branch  will  maintain  a  repository  of  all  data 
deliverables.  During  the  development  phase  of  the  program,  data  deliverables  will  be 
prepared  and  distributed  in  accordance  with  the  appropriate  Data  Item  Deliverables 
(DIDs),  CDRLs,  and  task  orders.  Procedures  for  receipt,  review,  and  acceptance  of 
the  data  are  contained  in  the  CMOS  CMP. 

e.  Reviews  and  Audits.  The  following  reviews  and  audits  will  be  conducted  to  evaluate 

and  assess  work  to  date  and  authorize  work  to  continue. 

(1)  System  Requirements  Review  (SRR).  The  purpose  of  the  SRR  is  to  present  the 
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(1)  System  Requirements  Review  (SRR).  The  purpose  of  the  SRR  is  to  present  the 
development  contractor's  understanding  of  the  system  requirements  and  to  receive 
feedback  concerning  the  preliminary  System/Segment  Specification. 


(2)  System  Design  Review  (SDR).  At  the  completion  of  the  System  Design  phase  a 
System  Design  Review  will  occur.  The  SSDD,  Preliminary  SRS,  RTM,  and  Updated 
SDP  will  be  provided  to  the  review  committee  prior  to  the  review.  This  review  will 
evaluate  the  allocation  of  the  technical  requirements,  previously  defined  in  the  SSS, 
to  hardware,  software,  and  communications.  The  review  committee  will  evaluate  the 
process  used  to  <v  velop  the  allocation  along  with  the  risks  associated  with  the  system 
design.  The  Fui.  Jonal  Baseline  is  established  at  the  successful  conclusion  of  the 
SDR. 

(3)  System  Specification  Review  (SSR).  At  the  completion  of  the  Software 
Requirements  Analysis  phase  the  SSR  will  occur.  The  SRSs,  IRSs,  updated  RTM 
and  SDP  will  be  provided  to  the  review  committee  prior  to  the  review.  This  review 
will  ensure  that  system  requirements  have  been  properly  allocated  to  software  units. 
The  Allocated  Baseline  is  established  at  the  successful  conclusion  of  the  SSR. 

(4)  Preliminary  Design  Review  (PDR).  At  the  completion  of  the  Preliminary  Design 
phase,  the  top  level  design  will  be  reviewed  in  the  PDR.  All  products  will  be  provided 
to  the  review  committee  prior  to  its  convening.  The  PDR  will  ensure  that  the 
developer  has  prepared  all  appropriate  documentation,  in  addition,  the  developer  will 
present  all  software  quality  evaluation  findings  from  the  Preliminary  Design  Phase. 

(5)  Critical  Design  Review  (CDR).  The  objective  of  the  CDR  is  to  determine  whether 
the  design  adequately  addresses  all  the  performance  and  interface  requirements  of 
the  configuration  item.  This  is  a  technical  review  prior  to  the  beginning  of  coding  and 
will  be  conducted  prior  to  detail  design  release. 

(6)  Test  Readiness  Review  (TRR).  The  TRR  will  review  the  readiness  of  all 
testability  aspects  of  the  contractor's  development  effort.  The  satisfactory  conclusion 
of  the  review  indicates  the  developer's  readiness  to  begin  CSCI  testing. 

(7)  Functional  Configuration  Audit  (FCA).  The  objective  of  the  FCA  is  to  verify  that 
the  configuration  item’s  actual  performance  complies  with  the  approved  software 
functional  requirements. 

(8)  Physical  Configuration  Audit  (PCA).  The  objective  of  the  PCA  is  to  verify  that  the 
configuration  item  "as  built"  conforms  to  the  technical  documentation  which  defines 
the  configuration  item.  The  Product  Baseline  is  established  at  the  successful 
conclusion  of  the  PCA. 

(9)  Formal  Qualification  Review  (FQR).  The  objective  of  the  FQR  is  to  analyze  a 
group  of  configuration  items  comprising  the  system  to  ensure  they  have  met  specific 
contracting  agency  contractual  performance  requirements  (specifications  or 
equivalent). 

f.  Test  and  Evaluation.  Test  and  evaluation  can  be  broken  down  into  two  main  phases, 
Qualification  Test  and  Evaluation  (QT&E)  and  Qualification  Operational  Test  and 
Evaluation  (QOT&E),  supported  by  review  points.  A  brief  summary  of  QT&E  and  QOT&E 
is  described  below.  For  additional  information  refer  to  the  CMOS  Test  and  Evaluation 
Master  Plan  (TEMP). 
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(1)  Qualification  Test  and  Evaluation  (QT&E).  QT&E  will  be  conducted  to  determine 
if  the  designed  system  meets  its  specifications.  QT&E  I  will  be  used  to  accomplish 
coding  and  unit  testing,  computer  software  configuration  item  (CSCI)  testing,  and 
system  integration  testing.  QT&E  II  will  test  the  system  in  a  "field"  environment  prior 
to  operational  testing  performed  by  outside  agencies. 

(2)  Qualification  Operational  Test  and  Evaluation  (QOT&E).  QOT&Ewillbe 
conducted  to  determine  the  system's  operational  effectiveness  and  suitability.  This 
testing  will  be  accomplished  in  as  close  to  an  operational  environment  as  possible  by 
an  independent  test  agency.  QOT&E  will  utilize  actual  operations  and  maintenance 
personnel  for  conducting  the  testing. 

(3)  TRR.  Testing  will  be  supported  with  a  test  readiness  review  to  determine  if  the 
system  is  ready  to  proceed  to  the  next  level  of  testing.  It  will  be  accomplished  before 
formal  CSCI  testing  begins  (refer  to  Figure  8-1).  Achievement  of  a  satisfactory  FCA, 
PCA  and  FQR  prior  to  QOT&E  will  provide  the  basis  for  the  Program  Manager  to 
certify  that  the  system  is  ready  to  begin  QOT&E. 

g.  Software  Quality.  Software  Quality  Evaluation  (SQE).  The  SQE  will  provide  the 
program  manager  a  means  to  determine  that  the  system  and  its  components  meet  quality 
assurance  (QA)  requirements.  QA  is  vital  in  the  identification  and  measurement  of  product 
quality  degradation  and  reduces  the  possibility  that  production  and/or  acceptance  of  defects 
will  occur. 

h.  Security. 

(1)  General.  Security  for  the  CMOS  program  will  conform  with  AFR  205-16  and 
other  applicable  DOD  and  Air  Force  directives. 

(2)  Computer  Security.  All  CMOS-acquired  Automated  Data  Processing  Equipment 
(ADPE)  shall  conform  with  the  ADP  security  requirements  of  DOD  Standard  5200.28. 


29 


9.  Transition  Management  Practices. 

a.  Configuration  Management 

(1)  Configuration  Management  (CM)  is  a  formal  management  process  to  be  applied 
to  the  CMOS  Program.  The  CM  function  includes  identification  of  hardware  and 
software  configuration  items  (design  units),  change  control,  configuration  status 
accounting,  reviews  and  audits. 

(2)  Configuration  Management  Concept . 

(a)  The  CMOS  CMP  details  CMOS  CM  policies  and  procedures.  The  CMP 
identifies  the  disciplines  necessary  to  establish  baseline  characteristics  and 
control  changes.  Baselines  will  be  employed  throughout  the  development 
process  to  ensure  an  orderly  transition  from  one  major  commitment  point  to  the 
next.  As  new  requirements  or  changes  to  the  baselined  configuration  items 
(CIs)  are  identified,  they  will  be  evaluated  for  program  impact.  A  CCB  will 
analyze  the  impact  of  each  proposed  change  and  make  a  recommendation  to 
the  Program  Manager.  Interface  control  policies  and  procedures  will  be 
established  as  needed. 

(b)  Selected  configuration  status  reports  will  be  maintained  to  identify  the 
history  and  status  of  each  Cl  and  all  changes  thereto. 

(c)  Reviews  and  audits  will  provide  program  visibility  as  well  as  help  to  assure 
that  the  contractor  provides  a  quality  product. 

b.  Turnover.  Responsibility  for  CMOS  will  remain  with  SSC/LGTT  for  the  intended  life  of 
the  system. 

c.  Support  During  Transition.  This  paragraph  does  not  apply  to  CMOS  since  no 
transition  is  planned  for  the  system. 

d.  Transfer.  No  transfer  of  computer  resources  is  planned  for  CMOS. 
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10.  Deployment  Management  Practices, 
a.  Boards  and  Committees. 

(1)  Configuration  Control  Board.  The  CC8  is  composed  of  representatives  from 
CMOS  program  functional  areas,  SSC  support  agencies,  and  participating 
commands.  The  CMOS  Program  Manager  or  his  designated  representative  will  chair 
and  direct  each  CCB  meeting.  The  procedures  for  this  board  are  defined  in  the  CMP. 

(a)  Responsibilities. 

1)  Configuration  control  of  CMOS  software  and  hardware  developed  or 
acquired  during  CMOS  development. 

2)  Manage  established  baselines. 

3)  Act  on  proposed  changes  to  baselines. 

4)  Review  and  validate  all  program  impacts  by  approving  or 
disapproving  proposed  changes  to  an  approved  baseline. 

5)  Establish  and  implement  priorities. 

6)  Provide  configuration  management  guidance  and  direction  to 
operating  commands. 

(b)  Interfaces. 

1)  Evaluate  proposed  changes  pertaining  to  cost,  schedule,  or 
baseline  submitted  by  the  government  and/or  contractor. 

2)  Provide  MAJCOM  Software  Configuration  Control  Sub-Boards 
guidance. 


(2)  Computer  Resources  Working  Group.  The  CRWG  is  composed  of 
representatives  from  CMOS  program  functional  areas,  SSC  support  agencies, 
participating  commands,  supporting  commands,  and  operating  commands.  The 
chairman  of  the  CRWG  is  CMOS  Program  Manager  (SSC/LGTT),  who  will  coordinate 
and  direct  each  CRWG  meeting.  Specific  responsibilities  for  the  CRWG  are 
contained  in  the  CRWG  charter  contained  in  Appendix  D  of  this  document. 

(3)  Interface  Control  Working  Group.  The  ICWG  serves  as  the  official 
communr  .Jons  link  between  program  participants  to  resolve,  document,  and 
coordinate  external  interface  matters  with  other  major  programs  such  as  SBSS  and 
CAS-B.  Procedures  for  the  ICWG  are  contained  in  the  CMP. 

(4)  Computer  Security  Working  Group.  The  CSWG  is  chartered  as  an  advisory 
forum  with  organizational  and  computer  systems  security  expertise.  The  purpose  of 
the  CSWG  is  to  provide  CMOS  with  a  review  of  security  policy,  design,  and 
implementation  strategies. 

b.  Configuration  Management  See  Section  1  for  applicable  directives. 
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c.  Security. 


(1)  General.  Security  for  CMOS  program  will  conform  with  DOD  Directive  5200.28, 
DOD  5200.1-R/AFR  205-1.  DOD  5220.22-R/AFR  205-4,  AFR  205-16,  and  other 
applicable  DOD  and  Air  Force  directives. 

(2)  Computer  Security.  All  CMOS-acquired  ADPE  shall  conform  with  the  ADP 
security  requirements  of  DOD  Directive  5200.28,  DOD  5200.28-M,  DIAM  50-4,  and 
AFR  205-16.  The  Trusted  Computer  System  Evaluation  Criteria,  CSC-STD-001-83, 
may  apply  and  will  b?  used  as  appropriate. 

(3)  Physical  Security.  The  system  physical  security  for  CMOS  will  be  performed  in 
accordance  with  AFR  205-16.  MAJCOM  sites  will  perform  and/or  update  the 
necessary  Security  Risk  Assessments  and  Security  Risk  Plans. 


d.  Training.  CMOS  operational  training  requirements  will  be  supported  by  MAJCOM 
implementation  training  teams,  a  System  Manager  course,  a  Mobility  Training  Module,  and 
ATC  basic  transportation  courses.  MAJCOMs  will  conduct  on-the-job  training  (OJT)  to 
satisfy  those  requirements  that  fall  within  the  responsibility  of  the  MAJCOM  (i.e., 
qualification,  upgrade,  special  certification,  follow-on,  etc.).  Training  tasks  and  objectives 
will  be  determined  by  application  of  the  Instructional  Systems  Development  (ISD)  program 
IAW  AFR  50-8. 

System  Manager  training  will  involve  approximately  two  weeks  of  classroom  instruction.  It 
will  cover  all  aspects  of  system  administration,  system  management,  user  management, 
data  management,  trouble  shooting,  and  preventative  maintenance  and  problem  reporting. 

The  Mobility  Training  Module  will  provide  an  advanced  training  course  for  transportation 
and  base  level  logistics  plans  personnel.  The  course  will  be  held  during  the  initial  state  of 
CMOS  deployment  to  provide  additional  training  in  mobility  operations.  The  objective  of 
the  course  will  be  to  cover  advanced  topics  not  covered  during  the  implementation  training 
and  to  train  transportation/logistics  personnel  on  how  to  train  mobility  augmentees. 

Air  Training  Command  (ATC)  basic  transportation  courses  will  begin  development  in  FY 
93/94.  CMOS  will  be  implemented  in  subject  courses  at  the  appropriate  ATC  center  in  FY 
96.  Training  requirements  for  these  courses  will  be  determined  by  the  user  and  submitted 
to  HQ  ATC  no  later  than  the  fourth  quarter  of  FY  92. 

Implementation  training  will  be  provided  at  each  base  prior  to  CMOS  startup.  This  training 
will  be  a  joint  effort  between  the  MAJCOMs  and  the  CMOS  SPO.  The  SPO  schedules 
activities,  the  MAJCOM  notifies  their  team,  and  the  team  executes  the  training. 
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11.  Schedules. 


a.  Major  Milestones.  Figure  11-1  identifies  the  major  milestones  associated  with  the 
acquisition,  transition,  and  support  schedules  of  the  system. 

b.  Contract  Deliverable  Schedule.  Reference  the  latest  CMOS  Monthly  Program  Status 
Report  for  a  summary  of  delivered  and  pending  items. 

c.  Support  Capabilities.  Figure  11-2  identifies  the  schedule  for  acquisition  and 
achievement  of  initial  operational  capability  (IOC)  for  the  primary  computer  resource 
support  capabilities. 


CA  SRR  SDR  SSR  PDR  CDR  FCA/PCA 


Contract  Award 
Establish  CCB 

Update  Subsystem  Specifications 
Submit  Subsystem/Segment  Design 
Establish  Functional  Baseline 
Submit  Interface  Requirements  Specifications 
Submit  Software  Requirements  Specifications 
Establish  Allocated  Baseline 
Submit  Software  Test  Plan 
Submit  Software  Design  Document 
Submit  Interface  Design  Document 
Submit  Software  Test  Descriptions 
Submit  Source  Code 
Submit  Software  Test  Reports 
Submit  Computer  Systems  Operations  Manual 
Submit  Software  Users  Manual 
Submit  Programmers  Manual 
Submit  Version  Description  Document 
Submit  Software  Products  Specifications 
Establish  Product  Baseline 


Figure  1 1  -1 .  Major  Milestones. 
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Figure  11-2.  CMOS  IOC  Schedule. 
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D.  Computer  Resources  Working  Group  (CRWG)  Charter 

E.  Risk  Management  Plan 
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ACA 

ACSN 

AORSS 

ADP 

AFC2S 

AFLC 

AFMC 

AFR 

ATC 

AUTODIN 

B-TWRAPS 

BLAMES 

CALM 

CAPS 

CAS-B 

CCB 

CCP 

CDCP 

CDR 

Cl 

CLIN 

CDRL 

CM 

CMOS 

CMP 

COMPES-B 

COMSEC 

COTS 

CRLCMP 

CRWG 

CSC 

CSCI 

CSU 

CSWG 

DAMMS-R 

DDL 

DDN 

DID 

DODD 

DOOR 

DOD-STD 

DTL 

ECP 

EDI 

ESL 

ETADS 

FAR 

FCA 

FOR 

GFE 

GFS 
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Acronyms  and  Abbreviations 

Air  Clearance  Authority 

Advance  Change  Study  Notice 

Automated  Data  Reports  Submission  System 

Automated  Data  Processing 

Air  Force  Command  and  Control  System 

Air  Force  Logistics  Command 

Air  Force  Materiel  Command 

Air  Force  Regulation 

Air  Training  Command 

Automatic  Digital  Network 

Base-Transportation  Workload  Reporting  and  Productivity  System 

Base  Level  AUTODIN  Message  Extraction  System 

Computer  Aided  Load  Manifesting 

Consolidate  Aerial  Port  System 

Combat  Ammunition  System  -  Base 

Configuration  Control  Board 

Containerization  Consolidation  Point 

Central  Data  Collection  Point 

Critical  Design  Review 

Configuration  Item 

Contract  Line  Item  Number 

Contract  Data  Requirements  List 

Configuration  Management 

Air  Force  Cargo  Movement  Operations  System 

Configuration  Management  Plan 

Contingency  Operations/Mobiiity  Planning  and  Execution  System-Base 

Communications  Security 

Commercial  Off-the-Shelf 

Computer  Resources  Life  Cycle  Management  Plan 

Computer  Resources  Working  Group 

Computer  Software  Component 

Computer  Software  Configuration  Item 

Computer  Software  Unit 

Computer  Security  Working  Group 

Department  of  the  Army  Movement  Management-Redesign 

Data  Definition  Language 

Defense  Data  Network 

Data  Item  Deliverable 

Department  of  Defense  Directive 

Department  of  Defense  Regulation 

Department  of  Defense  Standard 

Development  and  Test  Laboratory 

Engineering  Change  Proposal 

Electronic  Data  Interchange 

Engineering  Support  Laboratory 

Enhanced  Transportation  Automated  Data  System 

Federal  Aquisition  Regulation 

Functional  Configuration  Audit 

Formal  Qualification  Review 

Government  Furnished  Equipment 

Government  Furnished  Software 


A-l 


GSS 

HHT 

HOST 

HWCI 

ICI 

ICWG 

IOD 

IOC 

IE 

IEEE 

ILS 

ILSP 

IOC 

IRS 

ISD 

ISRD 

IV&V 

Kb 

LAN 

LOGMARS 

MAJCOM 

Mb 

MIL-STD 

NDS 

OCONUS 

OJT 

OM 

OPR 

ORD 

PC 

PCA 

PDR 

PMD 

p3| 

RAM 

RDBMS 

RTM 

QA 

QOT&E 

QT&E 

SBSS 

sees 

SDD 

SDL 

SDP 

SDR 

SMSCRC 

SPM 

SPO 

SPS 

SQE 

SQL 

SRR 

SRS 


Graphics  Software  System 
Hand  Held  Terminal 

Headquarters  On-line  System  for  Transportation 

Hardware  Configuration  Item 

Interactive  Communications  Interface 

Interface  Control  Working  Group 

Interface  Design  Document 

Initial  Operational  Capability 

Information  Engineering 

Institutue  of  Electrical  and  Electronics  Engineers 
Integrated  Logistics  Support 
Integrated  Logistics  Support  Plan 
Initial  Operational  Capability 
Interface  Requirements  Specifications 
Instructional  Systems  Development 
Information  System  Requirements  Document 
Independent  Verification  and  Validation 
Kilobyte 

Local  Area  Network 

Logistics  Applications  of  Automated  Marking  and  Reading  Symbols 

Major  Command 

Megabyte 

Military  Standard 

Non-developmental  Software 

Outside  the  Continental  United  States 

On  the  Job  Training 

Operator's  Manual 

Office  of  Primary  Responsibility 

Operational  Requirements  Document 

Personal  Computer 

Physical  Configuration  Audit 

Preliminary  Design  Review 

Program  Management  Directive 

Pre-Planned  Product  Improvement 

Random  Access  Memory 

Relational  Data  Base  Management  System 

Requirements  Traceability  Matrix 

Quality  Assurance 

Qualification  Operational  Test  and  Evaluation 
Qualification  Test  and  Evaluation 
Standard  Base  Supply  System 
Source  Code  Control  System 
Software  Design  Document 
Software  Development  Library 
Software  Development  Plan 
Software  Design  Review 

Standard  Multi-user  Small  Computer  Requirements  Contract 

Software  Programmer's  Manual 

System  Program  Office 

Software  Product  Specification 

Software  Quality  Evaluation 

Structured  Query  Language 

System  Requirements  Review 

Software  Requirements  Specification 


ssc 

Standard  Systems  Center 

SSR 

Software  Specification  Review 

SSDD 

System/Segment  Design  Document 

sss 

System/Segment  Specification 

STD 

Software  Test  Description 

STP 

Software  Test  Plan 

STR 

Software  Test  Report 

TEMP 

Test  and  Evaluation  Master  Plan 

TERMS 

Terminal  Management  System 

TMO 

Transportation  Management  Office 

TPWG 

Test  Planning  Working  Group 

TRR 

Test  Readiness  Review 

ULANA 

Unifed  Local  Area  Network  Architecture 

UM 

User's  Manual 

UPS 

Uninterruptible  Power  Supply 

VGA 

Video  Graphics  Array 

VDD 

Version  Description  Document 

WCA 

Water  Clearance  Authority 
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Appendix  B 
Glossary  of  Terms 

Allocated  Baseline:  The  Initially  approved  documentation  describing  an  item's  functional  and 
interface  characteristics  that  are  allocated  from  those  of  a  higher  level  Cl,  interface  requirements 
with  interfacing  configuration  items,  additional  design  constraints,  and  the  verification  required  to 
demonstrate  the  achievement  of  those  specified  functional  and  interface  characteristics.  (MIL- 
STD-480B) 

Approved  Change:  A  change  for  which  approval  has  been  given  for  incorporation  by  the 
applicable  configuration  control  boand. 

Audits:  Configuration  audits  verify  conformance  to  specifications  and  other  contract 
requirements.  Audits  are  not  reviews.  NOTE:  Audits  differ  from  reviews  in  that  reviews  are 
conducted  on  a  periodic  basis  to  assess  the  degree  of  completion  of  technical  efforts  related  to 
identified  milestones  before  proceeding  with  further  technical  effort. 

Baseline:  A  configuration  identification  document,  ora  set  of  such  documents  (regardless  of 
media),  formally  designated  and  fixed  at  a  specific  time,  during  a  configuration  item's  life  cycle. 
Baselines,  and  their  approved  changes,  constitute  the  current  configuration  identification. 

Baseline  Management:  Applying  technical  and  administrative  direction  to  designate  the 
documents  which  formally  identify  and  establish  the  initial  configuration  identification  at  specific 
points  in  the  life  cycle.  (MIL-STD-483A) 

Class  I  Change:  Changes  to  baseline  specifications  and  products  are  designated  as  Class  I  when 
they  affect  one  or  more  of  the  following: 

a.  Baseline  configuration  identification. 

b.  Technical  requirements  to  include  performance  reliability  and  interface  characteristics. 

c.  Non  technical  effects  such  as  fees,  incentives,  cost  to  government,  schedules,  and 
guarantees. 

d.  Other  items  to  include  effects  upon  Government  Furnished  Equipment  (GFE),  safety, 
support  equipment  compatibility,  inadequate  funding,  etc. 

Class  II  Change:  Changes  not  affected  by  Class  I  factors  which  may  include  documentation  only 
changes,  hardware  substitutions,  and  program  changes  that  do  not  impact  cost  or  schedule  and 
fall  within  contractual  scope. 

Computer  Software  Component  (CSC):  A  functionally  or  logically  distinct  part  of  a  CSCI.  CSCs 
may  be  top-level  or  lower-level.  (AFR  800-14) 

Computer  Software  Configuration  Item  (CSCI):  A  configuration  item  for  computer  software. 
(DOD-STD-21 67  A) 

Configuration:  The  functional  and/or  physical  characteristics  of  hardware/software  as  set  forth  in 
technical  documentation  and  achieved  in  a  product.  (DODD  5010.19) 

Configuration  Control:  The  systematic  evaluation,  coordination,  approval  or  disapproval,  and 
implementation  of  all  approved  changes  in  the  configuration  of  a  CI/CSCI  after  formal 
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establishment  of  its  configuration  identification.  (DODO  5010.19) 

Configuration  Control  Board  (CCB):  A  board  composed  of  representatives  from  program/project 
functional  areas  such  as  engineering,  configuration  management,  procurement,  production,  test 
and  logistics  support,  training  activities,  and  using/supporting  organizations.  This  board  approves 
or  disapproves  proposed  changes  with  each  member  recording  his  organization's  official  position. 
The  program/project  manager  is  normally  the  board  chairman  and  makes  the  final  decision  on  all 
changes  unless  otherwise  directed  by  command  policy.  The  board  issues  a  directive/request  to 
implement  its  decision.  (AFR  800-14) 

Configuration  Item  (Cl):  An  aggregation  of  hardware/software,  or  any  of  its  discrete  portions, 
which  satisfies  an  end-use  function  and  is  designated  by  the  Government  for  configuration 
management.  During  development  and  initial  production,  CIs  are  only  those  specification  items 
referenced  directly  in  the  contract  (or  an  equivalent  in-house  agreement).  During  the  operation 
and  maintenance  period,  any  repairable  item  designated  for  separate  procurement  is  a 
configuration  item.  (DODD  5010.19) 

Configuration  Management:  A  discipline  applying  technical  and  administrative  direction  and 
surveillance  to  (a)  identify  and  document  the  functional  and  physical  characteristics  of  CIs,  (b) 
audit  the  CIs  to  verify  conformance  to  specifications,  interface  control  documents,  and  other 
contract  requirements,  (c)  control  changes  to  CIs  and  their  related  documentation,  and  (d)  record 
and  report  information  needed  to  manage  CIs  effectively,  including  the  status  of  proposed 
changes  and  the  implementation  status  of  approved  changes.  (DODD  5010.19) 

Critical  Design  Review  (CDR):  This  review  will  be  conducted  by  the  developer  for  each 
configuration  item  when  detail  design  is  essentially  complete.  The  purpose  of  this  review  will  be 
to  determine  if  the  detail  design  of  the  configuration  item  under  review  satisfies  the  design 
requirements  established  in  the  configuration  item  specification,  and  establishes  the  exact 
interface  relationships  between  the  configuration  item  and  other  items  of  equipment  and  facilities. 
(MIL-STD-1521B) 

Deficiencies:  Deficiencies  consist  of  two  types:  Conditions  or  characteristics  in 
handware/software  which  are  not  in  compliance  with  a  specified  configuration,  or  inadequate  (or 
erroneous)  configuration  identification  which  has  resulted  or  may  result  in  configuration  items  not 
fulfilling  approved  operational  requirements.  (DODD  5010.19) 

Development  Specification:  A  document  applicable  to  an  item  below  the  system  level  which 
states  performance,  interface,  and  other  technical  requirements  in  sufficient  detail  to  permit 
design,  engineering  for  service  use,  and  evaluation. 

Deviation:  A  specific  written  authorization,  granted  prior  to  the  manufacture  of  an  item,  to  depart 
from  a  particular  performance  or  design  requirement  of  a  specification,  drawing,  or  other 
document  for  a  specific  number  of  units  or  a  specific  period  of  time.  A  deviation  differs  from  an 
engineering  change  that  an  approved  engineering  change  requires  corresponding  revision  of  the 
documentation  defining  the  affected  item,  whereas  a  deviation  does  not  contemplate  revision  of 
the  applicable  specification  or  drawing.  (MIL-STD-480B) 

Documentation:  The  specifications,  reports,  plans,  and  procedures  used  to  document  and  support 
computer  programs. 

Engineering  Change:  An  alteration  in  the  approved  configuration  identification  of  a  Cl  under 
development,  delivered,  or  to  be  delivered.  Changes  may  be  Class  I  or  Class  II.  (MIL-STD- 
480B) 
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Formal  Qualification  Review  (FQR):  The  FQR  is  a  review  to  ensure  the  quality  control  tests  have 
been  accomplished  verifying  system  performance  according  to  specification  requirements.  An 
FQR  is  held  for  each  new  design.  (MIL-STD-1521B) 

Functional  Baseline  (FBL):  The  initially  approved  documentation  describing  a  system's  or  item's 
functional  characteristics  and  the  verification  required  to  demonstrate  the  achievement  of  those 
specified  functional  characteristics.  (MIL-STD-480B) 

Functional  Configuration  Audit  (FCA):  Formally  validates  the  development  of  a  Cl  has  been 
completed  satisfactorily  and  the  item  has  achieved  the  performance  and  functional  characteristics 
specified  in  the  functional  or  allocated  configuration  identification.  Includes  a  review  of  the 
completed  operation  and  support  documents.  (AFR  65-3) 

Physical  Configuration  Audit  (PCA):  Technical  examination  of  a  designated  Cl  to  verify  the  item 
"as  built"  conforms  to  the  technical  documentation  which  defines  it.  (MIL-STD-1521B) 

Preliminary  Design  Review  (PDR):  Conducted  for  each  Cl  or  aggregate  of  CIs  to:  (1)  evaluate 
the  progress,  technical  adequacy,  and  risk  resolution  (on  a  technical,  cost,  and  schedule  basis)  of 
the  selected  design  approach;  (2)  determine  its  compatibility  with  performance  and  engineering 
requirements  of  the  HWCI  development  specification;  (3)  evaluate  the  degree  of  definition  and 
assess  the  technical  risk  associated  with  the  selected  manufacturing  processes;  and  (4)  establish 
the  existence  and  compatibility  of  the  physical  and  functional  interfaces  among  the  Cl  and  other 
equipment,  facilities,  software  and  personnel.  For  CSCIs,  PDR  focuses  on:  (1)  the  progress, 
consistency,  and  technical  adequacy  of  the  selected  top-level  design  and  test  approach,  (2) 
compatibility  between  software  requirements  and  preliminary  design,  and  (3)  the  preliminary 
version  of  the  operation  and  support  documents.  (MIL-STD-1521B) 

Product  Baseline  (PBL):  The  initially  approved  documentation  describing  ail  of  the  necessary 
functional  and  physical  characteristics  of  the  Cl,  any  required  joint  and  combined  operations 
interoperability  characteristics  of  a  Cl  (including  a  comprehensive  summary  of  the  other  service(s) 
and  allied  interfacing  CIs  or  systems  and  equipment),  and  the  selected  functional  and  physical 
characteristics  designated  for  production  acceptance  testing  and  tests  necessary  for  support  of 
the  Cl.  (M I L-STD-480B) 

Software  Reliability:  The  probability  that  a  computer  program  configuration  item  will  perform  its 
intended  function  for  a  specified  interval  under  stated  conditions. 

Specification:  A  document  intended  primarily  for  use  in  procurement,  which  clearly  and 
accurately  describes  the  essential  technical  requirements  for  items,  materials,  or  services, 
including  the  procedures  by  which  it  will  be  determined  that  the  requirements  have  not  been  met. 
(DODD  4120.3) 

Specification  Change  Notice  (SCN):  This  document  is  used  to  propose,  transmit,  and  record 
changes  to  a  specification.  In  the  proposal  or  preliminary  form,  prior  to  approval,  the  SCN 
supplies  copies  of  the  pages  containing  the  proposed  changes.  (MIL-STD-480B) 

System:  A  composite  of  equipment,  skills,  and  techniques  capable  of  performing  and/or 
supporting  an  operational  (or  non-operational)  role.  A  complete  system  includes  all  equipment- 
related  facilities,  material,  software  services,  and  personnel  required  for  its  operation  and  support 
to  the  degree  it  can  be  considered  a  self-sufficient  item  in  its  intended  operational  (or  non- 
operational)  environment.  (MIL-STD-480B) 

System  Specification:  A  document  which  states  the  technical  and  mission  requirements  for  a 
system  as  an  entity,  allocates  requirements  to  functional  areas  (or  configuration  items),  and 
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defines  the  interfaces  between  or  among  the  functional  areas. 

System  Design  Review  (SDR):  Evaluates  optimization,  correlation,  completeness,  and  risks 
associated  with  the  allocated  technical  requirements.  Reviews  the  system  engineering  process 
which  produced  the  allocated  technical  requirements  and  the  engineering  planning  for  the  next 
phase  of  effort.  Reviews  basic  manufacturing  considerations  and  addresses  planning  for 
production  engineering  in  subsequent  phases.  Conducted  when  system  characteristics  are 
defined  and  CIs  are  identified.  (MIL-STD-1521B) 

System  Requirements  Review  (SRR):  Ascertains  the  adequacy  of  the  contractor's  effort  in 
defining  system  requirements.  Conducted  when  a  significant  portion  of  the  system  functional 
requirements  has  been  established.  (MIL-STD-1521B) 

Version  Description  Document:  This  data  item  shall  be  used  to  accompany  changes  to  an 
approved  and  released  computer  program.  Its  purpose  is  to  identify  the  changes  made  and  the 
exact  version  of  a  computer  program  to  be  delivered. 

Waiver  A  written  authorization  to  accept  a  configuration  item  or  other  designated  items,  which 
during  production  or  having  been  submitted  for  inspection,  are  found  to  depart  from  specified 
requirements,  but  nevertheless  are  considered  suitable  for  use  "as  is"  or  after  rework  by  an 
approved  method.  (DODD  5010.19) 
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Appendix  C 
List  of  Key  Personnel 


NAME 

GRADE 

ORGANIZATION 

PHQNS 

Joseph  J.  Berardino 

Colonel 

SSC/LGT 

416-3166 

James  E.  Wakely 

Major 

SSC/LGTT 

416-5709 

Thomas  E.  Maher 

GS-13 

SSC/LGTTE 

416-2534 

Walter  F.  Dzialo 

GS-12 

SSC/LGTTF 

416-2538 
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CMOS 

COMPUTER  RESOURCES  WORKING  GROUP  (CRWG) 
CHARTER 


1.  Background.  General  authority  for  forming  a  Computer  Resources  Working  Group  (CRWG) 
is  contained  in  APR  800-14,  which  defines  computer  resources  as  "the  totality  of  computer 
hardware,  computer  software,  and  associated  personnel,  documentation,  supplies,  and  services." 
This  Charter  governs  the  activities  and  conduct  of  CMOS  CRWG. 

1-1.  References.  The  following  references  apply  to  the  CRWG: 

a.  APR  800-14,  Life  Cycle  Management  of  Computer  Resources  in  Systems,  29 
September  1986. 

b.  HQ  USAP  PMD  5272(4 )/  PE  #3861  OF,  dated  5  December  1986,  as  revised  5  June 
1992. 

1-2.  Agreements.  The  following  agreements  between  participating  commands  and  agencies 
pertain  to  the  membership  or  operation  of  CMOS  CRWG: 


2.  Purpose.  The  CMOS  CRWG  is  a  management  policy  advisory  group  composed  of  members 
from  each  organization  that  is  involved  with  the  life  cycle  management  of  computer  resources  in 
CMOS  program.  The  purpose  of  the  group  is  to  provide  assistance  and  advice  to  the  CMOS 
Program  Manager  in  all  aspects  of  the  program  involving  computer  resources. 


3.  Scope.  The  CMOS  CRWG  will  address  life  cycle  and  program  management  of  computer 
resources  involved  in  the  development  of  CMOS,  and  the  acquisition  of  the  hardware, 
communications,  and  software  to  support  Air  Force  base  level  TMO. 

4.  Organization.  The  CRWG  will  be  chaired  by  CMOS  Program  Manager,  SSC/LGTT.  Each  of 
the  organizations  listed  below  will  provide  representatives  to  the  CRWG.  Each  organization 
should  appoint  a  primary  and  alternate  member.  Members  are  responsible  for  advising  the 
Recorder  when  the  primary  or  alternate  member  changes  and/or  when  the  alternate  will  attend  a 
given  meeting  in  place  of  the  primary. 

ORGANIZATION  STATUS 

SSC/LGTT  Chairperson 

SSC/LGTT  Recorder 

SSC/AQA  Member 


4-1.  Attendance  of  Technical  Advisors.  Technical  advisors  will  be  specifically  invited  by  the 
Recorder  when  the  Chairperson  deems  their  attendance  essential. 

4-2.  Attendance  of  Contractors.  Contractors  will  be  allowed  to  attend  CRWGs  only  with  the 
prior  approval  of  the  CRWG  Chairperson.  Contractors  may  be  excluded  from  attending  certain 
portions  of  any  given  CRWG.  When  contractors  attend  CRWGs,  they  will  function  in  an  advisory 
capacity  only;  they  will  not  be  allowed  to  vote  on  program  management  policies. 
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5.  Responsibilities.  The  following  responsibilities,  products  and  tasks  of  the  CRWG  and  its 
officers  are  assigned  according  to  AFR  800-14: 

5-1.  Chairperson.  The  CRWG  Chairperson  will: 

a.  Serve  as  the  primary  point  of  contact  on  life  cycle  management  matters  for  the  CMOS 
program. 

b.  Serve  as  the  CRWG's  voice  to  the  CMOS  program  management  staff  on  computer 
resource  life  cycle  management  matters. 

c.  Coordinate  with  other  CMOS  working  groups  as  necessary  (e.g.,  Test  Plan  Working 
Group  (TPWG)). 

d.  Convene  the  CRWG  as  required  to  revise  CMOS  CRLCMP  or  provide  technical 
advice. 

5-2.  Recorder.  The  CRWG  Recorder  (SSC/LGTT)  will: 

a.  Schedule  CRWG  meetings  called  by  the  Chairperson  and  notify  members. 

b.  Ensure  minutes  are  taken  and  verify  their  accuracy. 

c.  Serve  as  the  membership's  primary  point  of  contact  for  monitoring  action  items, 
and  passing  recommendations  to  the  program  office. 

d.  Establish  agendas  for  meetings  based  on  recommendations  from  the  members  and 
direction  of  the  Chairperson. 

e.  Prepare,  publish,  distribute,  and  update  the  CRWG  charter. 

f.  Prepare,  publish,  and  distribute  minutes  of  the  CRWG. 

5-3.  Members.  The  CRWG  Members  will: 

a.  Serve  as  their  organizations'  primary  points  of  contact  on  life  cycle  management 
matters. 

b.  Assist  in  the  preparation  and  review  of  management  documents  for  the  CMOS 
program  (e.g.,  the  CRLCMP). 

c.  Brief  their  organizations'  program  management  issues  and  concerns  to  the  CRWG 
as  necessary. 

d.  Ensure  their  organizations  are  fully  aware  of  any  CMOS  requirements  that  may 
impact  the  organization. 

e.  Respond  to  action  items  assigned  during  CRWGs. 

f.  Submit  proposed  agenda  items  to  the  CRWG  Recorder. 

5-4.  Advisors.  Advisors  to  the  CRWG  will: 

a.  Provide  technical  advice  on  issues  within  their  areas  of  expertise. 
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b.  Brief  the  CRWG  as  required  on  topics  within  their  areas  of  expertise. 

5-6.  Products  and  Tasks.  The  CRWG  plays  a  major  role  in  the  management  of  computer 
resources  in  the  CMOS  system.  The  CRWG  will: 

a.  Write,  update  as  necessary,  and  monitor  compliance  with  the  CRLCMP. 

b.  Monitor  compliance  of  the  program  with  computer  resources  policy,  plans, 
procedures,  and  standards. 

c.  Select  a  software  support  concept  and  document  it  in  the  CRLCMP. 

(1)  Describe  the  support  concept  in  sufficient  detail  to  account  for  system 
peculiarities  and  existing  conditions. 

(2)  Categorize  each  software  functional  requirement  as  either  a  mission  or 
system  function. 

(3)  Further  categorize  each  CSCI  as  either  a  mission  or  system  CSCI  after  the 
allocated  baseline  is  authenticated. 

d.  Actively  participate  in  all  aspects  of  the  program  involving  computer  resources 
(program  management  reviews,  design  reviews,  audits,  etc.). 

e.  Advise  the  program  manager  in  all  areas  relating  to  the  acquisition  and  support  of 
computer  resources. 

f.  Integrate  software  test  activities  with  the  overall  test  program  through  a  TPWG. 

g.  Assist  the  program  manager  to  identify,  assess,  and  control  risks  associated  with 
computer  resources. 

h.  Assess  how  much  and  what  type  of  flexibility  and  spare  capacity  (to  allow  for  growth 
during  development  and  modification  during  system  deployment)  is  cost-effective 

and  document  recommendations  in  the  CRLCMP. 

i.  Analyze  existing  software  support  facilities  and  tools  for  modification  or  upgrade 
when  evaluating  support  resources  alternatives. 

j.  Analyze  inter  service  support  alternatives  along  with  other  support  concepts. 

k.  Coordinate  the  application  of  computer  security  concepts  and  guidance  to  the  system. 

l.  Develop  alternatives  for  computer  resources  life  cycle  support. 

(1)  Develop  a  preliminary  allocation  of  software  support  responsibility. 

(2)  Study  the  potential  for  organic  and  contractor  support. 

(3)  Identify  candidate  organizations  for  performing  software  support. 

m.  Define  the  appropriate  scope  of  IV&V  and  develop  a  recommended  approach. 


n.  Evaluate  the  use  of  standard  equipment,  high  order  languages,  instruction  set 
architectures,  and  interfaces. 

o.  Identify  ant  prioritize  the  required  software  quality  factors  such  as  interoperability, 
portability,  flexibility,  usability,  reusability,  maintainability,  integrity,  reliability, 
correctness,  testability,  and  efficiency. 

6.  Procedures.  The  CMOS  CRWG  will  be  conducted  in  accordance  with  the  following 
procedures. 

6-1.  Meetings.  CRWG  meetings  will  be  held  at  the  call  of  the  CRWG  Chairperson  and  at  other 
times  as  deemed  appropriate.  CRWG  members  may  request  a  meeting  by  submitting  proposed 
agenda  items  to  the  CRWG  Recorder.  When  a  CRWG  meeting  is  anticipated,  the  members 
should  be  asked  to  propose  agenda  items.  All  the  items  on  the  agenda  should  be  sent  to  the 
members  far  enough  in  advance  of  the  CRWG  meeting  to  obtain  input  from  the  member 
organizations.  Each  organization  will  plan  and  fund  for  their  participation  at  the  meetings.  The 
CRWG  meeting  may  be  hosted  by  various  organizations  as  agreed  to  by  the  CRWG. 

6-2.  Action  Items.  The  CRWG  is  an  advisory  body  to  the  program  manager.  The  program 
manager  is  responsible  for  the  acquisition  management  of  the  system,  including  computer 
resources.  As  the  Chairperson,  the  program  manager  will  assign  management  issues  as  action 
items  to  members  of  the  CRWG  for  resolution.  Those  issues  may  also  be  brought  before  the 
CRWG  for  resolution.  If  the  CRWG  cannot  resolve  an  issue,  it  must  notify  the  program  manager 
who  is  still  responsible  for  resolving  the  issue  through  other  means  such  as  program  reviews, 
senior  level  steering  committees,  or  direct  contact  with  command  Office  of  Primary  Responsibility 
(OPR). 


Appendix  E 
Risk  Management  Plan 


A  Risk  Management  Plan  is  being  developed  for  CMOS  due  to  the  plan  to  change  hardware 
platforms  for  the  Host  Processor  software  and  is  due  to  be  completed  by  26  Feb  1993. 


Appendix  F 

Detailed  System  Description 

Refer  to  the  Final  System/Segment  Design  Document,  Change  02,  Increment  II,  dated  13 
December  1990,  for  a  detailed  description  of  CMOS  processors  and  CSCIs. 

i 

» 

I 

i 

I 

I 

I 

> 


I 


F-l 


Appendix  G 
Security  Assistance 

This  appendix  is  not  applicable  to  the  CMOS  Program.  There  are  currently  no  plans  for  sale  of 
CMOS  technology  to  foreign  countries. 
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